Onda 6: validação diferencial das 52 libcalls, clippy zerado e 5 bugs corrigidos - #27

Wave 4 of the libcall plan landed `cp.execFile` end to end — the IR op,
its validator, `lowerExecFileCall` with the full callback/options fence
ladder, the Rust emitter, the runtime, and the corpus programs 2911/2912
— but never claimed the member. `builtinModuleFnOf` found no
`child_process.execFile` row, so the fence in lower-calls.ts refused the
call with SC2020 before `lowerBuiltinModuleCall`'s dispatch could reach
the lowering. The whole slice was dead code and both corpus programs
were red in every lane.

- Add the `execFile` row to the child_process surface table, the same way
  spawn/fork/execFileSync carry canonical shapes while their real call
  completion is special-cased in `lowerBuiltinModuleCall`.
- Drop the stale "the callback form has no lowering — promisify it"
  fence hint, which now contradicts the implementation.
- Teach `sideEffectFreeOptionValue` about arithmetic over numeric
  LITERALS so `maxBuffer: 64 * 1024 * 1024` (2912) is accepted. Operands
  are restricted to literals on purpose: an identifier operand is a
  side-effect-free read, but arithmetic on it would run valueOf.
- Mark 2911/2912 `// @rust-only`: `cp.execFile` is a Rust-lane row in
  BACKEND_LIB_CALLS, so the C and LLVM lanes would refuse it. That is
  the upstream drift the plan records and does not fix.
- Regenerate surface-manifest.json (the row becomes status "static",
  backends ["rust"]) and the child-process.ts diagnostics snapshot, which
  now shows the per-site execFile/fork fences the fixture was written
  for instead of one blanket member refusal.

Verified: both corpus programs pass the Rust differential lane, and a
minimal execFile program's stdout/stderr/exit match Node byte for byte.

The zlib slice had NO compiling corpus coverage: 2921 — the one program
naming all eight calls — was red in every lane on `const gzipAlias =
gzip;`. An immutable alias of an OVERLOADED table-backed builtin is a
principled frontend refusal (SC2007 on the two call signatures, SC1090 on
library functions as values), and builtin aliasing has its own fixture in
2913, so the alias was never this program's subject. Call `gzip` directly
and the rest of the file is sound.

- 2921: drop the alias, mark `// @rust-only`. All eight spellings are
  Rust-lane rows in BACKEND_LIB_CALLS, so C and LLVM would refuse them —
  the upstream drift the plan records rather than fixes.
- 3278: the lifecycle contract the plan asks for and 2921 does not prove.
  Per codec: the callback is SCHEDULED (never inline — checked against a
  `returned` flag set after the call), fires EXACTLY ONCE (a counter
  printed with every settle), and a codec failure arrives as argument ONE
  with the call itself not throwing. Covers all four decoders over the
  same fixed garbage, the distinct truncated-gzip failure, unzip's
  auto-detection of both wrappers, five concurrent deflates each firing
  once, the empty-input stream, and crc32's seeded chaining plus its
  ERR_OUT_OF_RANGE. No compressed bytes are printed — they are
  zlib-version-dependent, so every encoder is proved through its decoder
  and only the fixed gzip framing is shown.

Both programs pass the Rust differential lane (stdout, stderr and exit
code byte-identical to Node 24) and between them name all eight libcalls.

Wave 2's sixteen crypto libcalls had no compiling corpus coverage. The
only program that named them, 2890, is red (four separate unsupported
forms), and the hash programs that do compile — 1534, 2820, 2821, 2870 —
all use the FUSED chain, which the frontend folds into one
hashDigestStr/hmacDigestStr call and which therefore never reaches a
single handle libcall.

Two programs, both `// @rust-only` (all sixteen rows are Rust-only in
BACKEND_LIB_CALLS):

3279 — the incremental handle surface. Every handle is stored in a
binding so the chain fast path stands down and the per-step calls run:
createHash/createHmac with string and byte keys, update with string and
bytes and with hex/utf8 input encodings, and both terminal digests.
Digests are deterministic, so they print in full. `hash.copy()` is tested
for real INDEPENDENCE: a shared prefix, then a divergent write on each
side, each compared against a separately built expected digest; a copy
taken and not written; and finalizing the copy without finalizing its
origin. Terminal state pins Node's asymmetry exactly — Hash throws
ERR_CRYPTO_HASH_FINALIZED on update, digest and copy after digest, while
Hmac throws on update but answers an EMPTY string on a second digest.

3280 — pbkdf2Sync and the randomness primitives. pbkdf2 is deterministic,
so its bytes print, and the one-iteration single-block derivation is
cross-checked against HMAC(password, salt || INT(1)) built from the Hmac
surface instead of a copied constant. Randomness is tested by INVARIANT,
never by byte: randomFillSync returns the same view, a windowed fill
leaves the bytes outside [offset, offset+size) at their marker, a
zero-size fill touches nothing, the rest forms cover the whole buffer and
from an offset, a Uint8Array target works, and 32 filled bytes are not
all zero. randomInt is drawn 400 times against both arities, checked for
range and integrality, and every value of a 3-wide range must appear —
a stuck or modulo-biased generator fails that. Out-of-range fills,
inverted, empty and fractional ranges assert their observable errors.

Both pass the Rust differential lane and between them name all sixteen
libcalls.

2961 and 2962 already reach `emitter.onFlex`/`emitFlex` and pass, but they
only prove that a computed event name works at all. Wave 3's claim is
stronger: the checked-dynamic path must keep the SAME lifecycle as the
typed one. 3281 pins that, `// @rust-only` like both existing programs'
family (the two rows are Rust-only in BACKEND_LIB_CALLS).

Covered: registration order; prependListener landing in front; function
IDENTITY (the same reference registered twice counts twice, fires twice,
and `off` removes one registration at a time); `once` firing exactly once
and leaving the remaining listeners intact; removal performed DURING an
emit — the removed listener still runs for the in-flight emit and is gone
for the next, because Node dispatches over a snapshot — plus the
self-removing and removeAllListeners-during-emit variants; emit with no
listener answering false; a LITERAL event name that the computed pattern
matches reaching the same bucket as the computed spelling; payload arity
through zero- and three-parameter listeners (a rest parameter cannot cross
the boundary, so arity is covered by fixed arities); number and string
payloads used as their real types on the far side; and the reserved
`error` event staying on its own typed bucket with the Error object
intact while flex listeners exist on the same emitter.

Passes the Rust differential lane, so every one of those orderings is
byte-identical to Node 24.

Running wave 4's own corpus programs for the first time turned up three
mismatches against Node in the child-stdin writer. Two of them are fixed
here; the third is an architectural gap recorded below.

2896-child-stdin-write-after-finish: the `Finished` dispatch cleared
`error_listeners` before running the finish listeners. The program writes
from inside its finish listener — Node's ERR_STREAM_WRITE_AFTER_END, which
must arrive on the stream's `error` event — so `child_writer_fail` found an
empty listener list, took its no-listener branch and threw the error
UNCAUGHT. The program died mid-output: the error line and the child's own
`exit` line never printed. The error listeners now survive finish, which
is also what Node does.

2898-child-stdin-spawn-failure: the husk stdin handed back for a child
that failed to spawn started `writable: false`, so a read before the error
landed answered false where Node answers true (Node returns a live
ChildProcess and reports ENOENT on a later turn).
`children_dispatch_one` already destroys the writer immediately before it
delivers the error, so the read from inside the `error` listener still
answers false — the asymmetry the program checks.

STILL RED, not fixed here: 2894-child-stdin-backpressure. Node's `write`
answers true for a 64 KiB + 1 write into an empty pipe because libuv
attempts the write inline on the calling thread, the kernel absorbs the
first 64 KiB, and only the 1-byte remainder counts against the high-water
mark. This writer hands the whole buffer to its writer thread and scores
backpressure by bytes handed over, so it answers false. The two agree on
large writes and disagree exactly at the boundary. Matching Node needs an
inline non-blocking write attempt on the main thread with only the
remainder queued — a writer redesign, and one that needs a dependency
decision, since `#![forbid(unsafe_code)]` rules out reaching for libc.

`cargo test` stays at 260 passing and clippy stays clean; 2896 and 2898
now pass the Rust differential lane.

The last two fork/IPC libcalls without corpus coverage were
`child.disconnect` (every existing program disconnects from the WORKER
side with process.disconnect()) and the bare `child.send(message)` with no
callback (every existing send passes one, which routes to child.sendCb).
Covering them exposed two divergences in the IPC channel.

`connected` was doing four jobs at once: the public flag, the send gate,
the fire-once guard on the disconnect event, and the liveness bit that
defers the child's exit event until the channel has drained. Because of the
last two, disconnect() could not clear it — so it only sent a command to
the channel thread, and `child.connected` kept answering true and
`child.send` kept answering true until a thread round trip completed. Node
closes the channel inside disconnect(): the next read is already false and
the next send is already refused.

Split the flag. `connected` is now the public, synchronous one, cleared
inside disconnect(). A new `open` carries the drain state, so the exit
event stays deferred and a message the worker thread had already framed
before the local disconnect is still delivered — the EOF guarantee the
plan asks for is unchanged, and the disconnect listeners still fire exactly
once, now guarded on `open`.

Second divergence: the `disconnect` EVENT arrived only on the channel
thread's round trip, so it landed AFTER the callback of a send issued right
after disconnect(). Node emits it on the tick following a local
disconnect(), i.e. before that callback. disconnect() now takes its
listeners and queues them itself; the later Disconnected event still fails
the pending send callbacks but finds no listener left to call.

3282 pins all of it: a spawned child with no IPC slot reads as not
connected (channel ABSENT) versus a forked child after disconnect (channel
DISCONNECTED); the bare send and a burst of framed messages, all five of
which the worker reports back even though the channel is torn down
immediately after the reply; both send callbacks settling exactly once,
the late one with the channel-closed error; and the worker writing its
exit code twice so the parent can confirm the last write is the one it
observes.

All five fork corpus programs — 2946, 2948, 2949, 2963 and 3282 — pass the
Rust differential lane. cargo test stays at 260 passing, clippy clean.